<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<meta charset="utf-8">
<link rel="stylesheet" type="text/css" media="screen" href="http://a.tbcdn.cn/app/dp/s/screen.css" />
<style>
#bd {margin-left:20px;margin-right:20px;}
</style>
<title>wd-gallery - markdown</title>
</head>
<body>
<div id="bd">

<h1>引言</h1>

<p>由于前端工程师的成长道路自成轨迹，这让（Web前端技术）这个专业看起来是如此的与众不同。甚至很多诸如Yahoo!这种大公司里的前端工程师也多是靠自身的野蛮生长，我行我素的写着各种hack【译注：hack是指手法肮脏但实现起来很简单且行之有效的解决方案，这类解决方案往往目光短浅，只解决眼前问题】。或许你曾经也是一名小公司里的“页面仔”（the web guy），那时的你几乎什么都干。当大公司开始利用这些之前未被发掘的资源时【译注：大公司在业务扩张的时候会伴随大量的招聘，这时会有不少小公司的前端工程师被招募进来，文中提到的“资源”即是指这些人】，团队协作的环境短时间内吸纳了很多“hacker”【译注：Hacker有“黑客”的意思，偏褒义，但这里的意思是指那些不守规矩我行我素的前端开发工程师】，这时这些hacker碰到了各种条条框框。单兵作战再也没了优势，所有那些自学成才和以自我为中心的人不得不开始思考如何才能在团队环境中生存下来。</p>

<p>我是在上世纪90年代末开始学习JavaScript的：靠的是自学。因为当时的JavaScript还很新潮，学习资料很少。和其他很多开发者一样，我通过不断钻研IE和Netscape Navigator来自学。我做各种尝试、梳理我所掌握的知识，我一遍遍反复试验，直到搞清楚其工作原理。幸运的是，这份好奇和勤勉为我带来了第一份工作。</p>

<p>在我职业生涯的第一个五年，我是一个“脚本仔”。在我最早呆过的两家公司里，没有人比我更了解JavaScript和Web开发了。所有问题不管是最简单的还是最复杂的，我都能搞定。我刚刚从学校毕业，是一名初出茅庐的小伙子，却有着一种危机感。因为我找不出能和我产生思想碰撞的人，并且在我遇到问题时也没有人能为我解难。我力争做到最好，因为我知道我是唯一能做到这样的人。</p>

<p>在这五年之中，我不断磨练我的技能。我会让我的做事方式和工作流程更为合理。我不用担心其他人去研究我的代码，因为别人都没有能力给我做代码review或为我的代码提交bugfix。我是一个纯粹意义上的Hacker：我行我素的写着代码，而且不用担心它会被修改。</p>

<p>在我职业生涯的第六年，我换了工作加入了一个团队，在这个团队中每个人都会为项目的各个方面贡献代码。我的主要精力不再是JavaScript和Web开发，而是大部分时间在写后端代码和SQL。同时，传统的后端工程师却开始被迫写前端（页面）代码。这种体验真真让我打开了眼界：我之前写代码的方式和团队其他人实在是格格不入，这是一个大问题。</p>

<p>我很快意识到要想更高效的参与团队开发，我写代码的方式必须和团队保持一致。后台代码和SQL对我来说有点陌生，因此我采纳了身边一些有头脑的人写代码的模式。与此同时，我开始与其他工程师讨论我们应当采纳何种HTML、CSS和JavaScript的编程模式。我甚至在编译阶段加入了JavaScirpt语法检查来强制推行标准——这也是我第一次在公司做web代码的检查。不久以后，这个团队就像上了润滑油的机器一样高效。</p>

<p>我在2006年加入了Yahoo!。我一到Yahoo!就发现几乎所有工作都和相互协作有关。整个团队就像把不同的动物纠集在一起。我所加入的第一个团队是My Yahoo!团队，这个团队非常庞大，比我之前呆的任何团队都要大。团队里也有很多成型的编程指南，我有很多需要学习。新技术，新流程，以及新工具一股脑的展现在我面前。我花了大量的时间来学习这些新环境和吸收新知识，而这些知识是我从大学里接触不到的。在这里我完全沉浸在知识的海洋里，感觉自己像被重塑了一般。</p>

<p>几个月后，我开始遇到一些问题。我所习惯了的开发流程并不总是好好工作。有不少人以不同的方式来做事，这导致了很多bug。我的主管意识到了这个趋势，一天他把我叫到一边告诉我他希望我来负责梳理我们的开发。现在回想起他的话依然是那么鼓舞人心：“你写的代码都可以运行的很好，它们很少出bug。我希望其他人都像你一样写代码”。就这样，我打算着手为My Yahoo!前端开发组注入一些结构和规范。</p>

<p>我为My Yahoo!团队做的工作非常成功，最终我被遴选为2008年Yahoo!新版首页的首席前端工程师。这次委任让我有机会将我的代码组织和测试高质量代码的技巧应用于一个拥有20名前端工程师的团队，来让这20名工程师只开发一种（风格的）代码。通过几个月的学习和调整，这个团队的生产效率和产品质量到达了一个很高的水平，让很多人叹为观止。不管是谁写的代码，它们都看起来像出自一个人之手，此外，多数工程师都可以快速的接手别人的工作来修复bug或开发新功能。这期间作为一个工程师团队所产出的业绩在过去的几年里一直是我职业生涯最大亮点。</p>

<p>我在Yahoo!的这段时间都是在参与大型的团队开发，我将这期间的所有积累整理出来成书与此。所讨论的主题也是关于我的这种蜕变，我从一名我行我素的独行侠，蜕变为一名软件工程师，一名团队协作者，我放弃了我身上固有的侠气和个性，来让整个团队以更高的水准运作。这正是这本书的内容：如何站在团队的角度去写JavaScript代码。</p>

<p>开发者最不容易理解的事情是，我们为何需要花这么多时间来“维护”代码。很少有人会打开一个文本编辑器开始涂涂抹抹的写代码。大多数时间里，你所面对的代码已经写好的。以一种可维护的方式来写代码，可以让你和协作者很容易就知道上段代码写到什么地方什么程度。正如我在Yahoo!时常说的：“当你开始工作时，你不是在给你自己写代码，而是为后来人写代码”。</p>

<p>本书收集了很多关于JavaScript编程规范的讨论。“Java语言编码规范”（Code Conventions for the Java Programming Language）【译注：“Java语言编码规范”中译文地址：http://huihoo.org/code/java<em>code</em>conventions.html ，by moyingzz@etang.com 】是当前最流行的关于编码规范的文档之一，它指出编码规范如此之重要的几个原因：</p>

<ul>
<li>软件生命周期中80%的成本消耗在了维护上</li>
<li>几乎所有的软件的维护者都不是它的最初作者</li>
<li>编码规范提高了软件的可读性，它让工程师能够快速且充分的理解新的代码</li>
<li>如果你将源码作为产品来发布，你需要确保它是可完整打包的，且像你创建的其他产品一样整洁</li>
</ul>

<p>这些原因在今天看来依然适用。本书所讨论的编程规范也是着眼于帮你和你的团队写出高效的JavaScript代码。</p>

<p>因为你正在阅读这本书，你需要对本书提到的一些建议保持开放的心态。要知道这里说的很多技术，是为了解决多人开发的环境中很多工程师如何书写统一风格的代码的问题的。作为团队里的一员，意味着做出这种决策不仅对个人有好处，对于团队也同样有好处。对于个人来说，需要一定程度上牺牲个人偏好、个人观点甚至个人英雄主义。你所收获的是一个能做大事的高效的团队，我希望这本书可以帮助你做到这一点。</p>
</div>
</body>
</html>
